1. Field of the Invention
The present invention is related to network management. In particular, the present invention is related to a method and apparatus for management of configuration in a network.
2. Description of the Related Art
Network management stations perform network management functions including, but not limited to, fault detection, configuration of network elements, performance management, and security management. Typically, a network management station (NMS) invokes management software to communicate with agent software associated with network elements such as switches, routers, gateways, bridges, etc.
In the Internet, the protocol commonly used to communicate between a NMS and network elements is the Simple Network Management Protocol (SNMP). The set of specifications that define SNMP and associated databases may be found in Request For Comments (RFC) 1155, 1213, and 1157. SNMP defines both the syntax and semantics of the messages that a NMS and agents exchange.
In addition to the SNMP, separate standards for Management Information Bases (MIB) define the objects that SNMP maintain, the operations allowed, and the meaning of the specified operations. For example, the MIB for the Internet Protocol (IP) specifies that the SNMP agent must keep a count of all octets that arrive over each network interface of a router and that the network managing station can only read the count. MIB variables may specify network status parameters and track various aspects of the status of a network. By keeping MIBs independent of the SNMP, additions to MIBs can be defined without affecting the installed base of SNMP based network management stations, and the protocol can be used to communicate with network elements that have different versions of the same MIB.
In order to configure and manage network elements, the NMS uses a fetch-store paradigm. The SNMP get-request and set-request commands are the basic fetch and store operations respectively. The SNMP trap command enables a network element to communicate asynchronously with a NMS. The trap command is initiated by an SNMP agent associated with the network element, and provides the NMS with notification of some significant event as to the status of the network element. Specific traps may be user defined, and the SNMP agent may transmit an SNMP trap command when one or more user defined object values change. In SNMP trap-directed polling, information regarding a change in the network element is included in the trap packet sent to the NMS.
The use of traps to communicate information to the NMS is unreliable as traps can be lost due to the connectionless oriented nature of the SNMP. For management of configuration, lost traps are problematic because tracking network configuration requires that all changes in a network are reported to the NMS. Usually, network management stations regularly poll network elements in the network for the status and configuration of their managed objects. Based on the information regarding the managed objects obtained from the agent associated with the network element, the NMS may take some action. However, the polling mechanism used for configuring and monitoring networks is inefficient, especially if the NMS manages a large number of network elements. Periodic polling utilizes network capacity as polling is initiated by network management stations even when there may be no change in the objects that are being monitored. What is needed, therefore, is a more efficient method to configure and monitor network elements.